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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 

The present document is part 5 of a multi-part deliverable. Full details of the entire series can be found in 
part 1 [1]. 



Introduction 



Business and administrative relationships among companies, public administrations and private citizens, are the more 
and more implemented electronically. Trust is becoming essential for their success and continued development of 
electronic services. It is therefore important that any entity using electronic services have suitable security controls and 
mechanisms in place to protect their transactions and to ensure trust and confidence with their partners. 

Electronic mail is a major tool for electronic business and administration. Additional security services are necessary for 
e-mail to be trusted. At the time of writing the present document, in some European Union Member States (Italy, 
Belgium, etc.) regulation(s) and application(s) are being developed, if not already in place, on mails transmitted by 
electronic means providing origin authentication and proof of delivery. A range of Registered E-Mail ("REM") services 
is already established and their number is set to grow significantly over the next few years. Without the definition of 
common standards there will be no consistency in the services provided, making it difficult for users to compare them. 
Under these circumstances, users might be prevented from easily changing to alternative providers, damaging free 
competition. Lack of standardization might also affect interoperability between REM based systems implemented based 
on different models. The present Technical Specification is to ensure a consistent form of service across Europe, 
especially with regard to the form of evidence provided, in order to maximize interoperability even between e-mail 
domains governed by different policy rules. 

In order to move towards the general recognition and readability of evidence provided by registered e-mail services, it is 
necessary to specify technical formats, as well as procedures and practices for handling REM, and the ways the 
electronic signatures are applied to it. In this respect, the electronic signature is an important security component to 
protect the information and to provide trust in electronic business. It is to be noted that a simple "electronic signature" 
would be insufficient to provide the required trust to an information exchange. Therefore the present Technical 
Specification assumes the usage of at least an Advanced Electronic Signature, with the meaning of article 2(2) of EU 
Directive 1999/93/EC [i.l] issued with a Secure Signature Creation Device, with the meaning of article 2(6) of the same 
Directive. 
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Scope 



The present document profiles the implementation of TS 102 640 (REM TS) based systems, addressing issues relating 
to authentication, authenticity and integrity of the information to achieve interoperability between such systems. 

The present document covers all the options to profile REM-MD for both styles of operation: S&N and S&F. 

The mandatory requirements defined in the referenced REM TS are not repeated here but when necessary, the present 
document contains some references to them. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 1: Architecture". 

[2] ETSI TS 102 640-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 2: requirements, Formats and Signatures for REM". 

[3] ETSI TS 102 640-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 3: Information Security Policy Requirements for REM Management Domains". 

[4] Void. 

[5] IETF RFC 3207 (2002): "SMTP Service Extension for Secure SMTP over Transport Layer 

Security". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a 

Community framework for electronic signatures. 
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Definitions 



For the purposes of the present document, the terms and definitions given in TS 102 640-1 [1] apply. 
Throughout the present document a number of verbal forms are used, whose meaning is defined below: 

• shall, shall not: indicate requirements strictly to be followed in order to conform to the present document and 
from which no deviation is permitted. 

• should, should not: indicate that among several possibilities one is recommended as particularly suitable, 
without mentioning or excluding others, or that a certain course of action is preferred but not necessarily 
required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. 

• may, need not: indicate a course of action permissible within the limits of the present document. 



General requirements 



This clause describes the tools and the formalities used for defining the profiles in the present document. 



4.1 Compliance requirements 



Requirements are grouped in three different categories, each one having its corresponding identifier. Table 1 defines 
these categories and their identifiers. 

Table 1 : Requirement categories 



Identifier 


Requirement to implement 


M 


System shall implement the element 


R 


System should implement the element 


O 


System may implement the element 



All the requirements will be defined in tabular form. 

Table 2: Requirements template 



N 2 


Service/Protocol 
element 


TS reference 


Requirement 


Implementation 
guidance 


Notes 







































Column N° will identify a unique number for the requirements. This number will start from 1 in each clause. The 
eventual references to it would also include the clause number to avoid any ambiguity. 

Column Service/Protocol element will identify the service element or protocol element the requirement applies to. 

Column TS Reference will reference the relevant clause of the standard where the element is defined. The reference is 
to TS 102 640-1 [1], TS 102 640-2 [2] or TS 102 640-3 [3] except where explicitly indicated otherwise. 

Column Requirement will contain an identifier, as defined in table 1 . 

Column Implementation guidance will contain numbers referencing notes and/or letters referencing explanation of the 
requirement. It is intended either to explain how the requirement is implemented or to include any other information not 
mandatory. 

Column Notes will contain additional notes to the requirement. 

NOTE: Within one REM-PD may be in force provision different from the ones specified in the present document, 
if and only if such REM-PD does not envisage to interoperate with other REM-PDs. 
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5 REM profile for SMTP interoperability 

This clause defines a profile for interoperability among REM-MDs based on SMTP relay protocol. 



5.1 Style of operation 



From an interoperability standpoint, the style of operation adopted by a REM-MD (Store and Forward vs. Store and 
Notify) is foreseen to have no impact, so it is feasible to deal with both of them in a single profile. 

The reason for that lies in the fact that any REM-MD Message exchanged between two REM-MD (even REM-MD 
Messages that contain a reference to the REM Object in a Store- And-Notify context) is conveyed using the Relay 
Interface which, within the present interoperability profile, is based on the SMTP protocol. Henceforth protocols, 
message formats and evidence formats are the same in the two cases. 

Then all the Store-And-Notify systems also need a Store-And-Forward system that represents a common layer among 
the two styles of operations. 

Differences only arise in the set of mandatory evidence which are dealt with in the two styles of operations, as described 
in clause 5.4. 



5.2 



REM interfaces 



5.2.1 REM-MD Sender Message Submission Interface 



N 2 


Service/Protocol 
element 


TS 102 640-1 [1] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Any protocol provided 
that it is secured 


Clause 5 


M 


a 





Implementation guidance: 

a) The Message Submission interface shall be implemented using any protocol securing the communication from 
the originating mail User Agent to the SMTP server. As an example SMTP on TLS or SSL may be used. 

5.2.2 REM-MD Sender/Recipient Message Store Retrieval Interfaces 



N 2 


Service/Protocol 
element 


TS 102 640-1 [1] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Any protocol provided 
that it is secured 


Clause 5 


M 


a 





Implementation guidance: 

a) The Message Store Retrieval interface shall be implemented using any protocol securing the communication 
from the sender/recipient mail User Agent to the REM-MD server. As an example IMAP or POP on TLS or 
SSL may be used. 

5.2.3 REM-MD Repository Retrieval Interface 



N 2 


Service/Protocol 
element 


TS 102 640-1 [1] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Any protocol provided 
that it is secured 


Clause 5 


M 


a 
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Implementation guidance: 
a) 



The Repository Retrieval interface shall be implemented using any protocol securing the communication from 
the sender/recipient mail User Agent to the REM-MD server. As an example HTTP on SSL may be used 
(other common protocols like FTP and TLS for securing may be used and different agreements may exists 
between the involved REM-MDs). 



5.2.4 REM Object Relay Interface 



N 2 


Service/Protocol 
element 


TS 102 640-1 [1] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


SMTP on TLS 


Clause 5 


M 


a 


see note 


NOTE: This is a profile for SMTP relay protocol among REM-MDs and it reflects in this requirement. 



Implementation guidance: 

a) The Object Relay interface shall be implemented using SMTP protocol securing the communication from the 
sender REM-MD server to the recipient REM-MD server using TLS according to [5]. 

5.3 REM-MD Envelope 

5.3.1 REM-MD Message/REM Dispatch Headers Constraints 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


X-REM-Msg-Type 


Clause 4.1 


R 


a 




2 


X-REM-<component> 


Clause 4.1 


R 


b 





Implementation guidance: 
a) 



b) 



The headers list should contain a "X-REM-Msg-Type:" header specifying the type of the actual message. Its 
value will be either "Dispatch" for a REM Dispatch message or "Message" for a REM-MD. 

The headers list should contain at least three "X-REM-<component>:" headers specifying the following 
couples components/values: 

X-REM-Evidenceldentifie r. <valuel>: (i.e. GOO - REM-MD Evidence Identifier defined in 
clause 5.2.2. 1 . 1 of TS 102 640-2 [2]). 

X-REM-EvidenceType: <value2>: (i.e. G01 - REM-MD Evidence Type defined in clauses 5.1 of 
TS 102 640-2 [2]). 



X-REM-EventCode: <value3> 
TS 102 640-2 [2]). 



(i.e. G02 - REM Event defined in clause 5.2.2.1.3 of 



Where the values shall be filled respectively as: 

<valuel> a string UID according to clause 5.2.2.1.1 of TS 102 640-2 [2]. 

■ <value2> one of the values of the string "name" specified in clause B.2 of TS 102 640-2 [2] 
(e.g. SubmissionAcceptanceRejection, RelayToREMMDAcceptanceRejection, etc.). 

■ <value3> number representing the "eventCode" according to clause A. 1.1 of 
TS 102 640-2 [2]. 

NOTE: Items 1 and 2 facilitate achieving interoperability, that, however, may also be achieved without them. 
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5.3.2 REM-MD Signature Headers Constraints 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Content-Type 


Clause 4.3 


M 


a 




2 


Content-Disposition 


Clause 4.3 


M 


b 





Implementation guidance: 

a) The Content-Type header field shall be present. The value of the header shall be 
"application/pkcs7-signature". An additional "name" parameter shall be provided that has the value 
"smime.p7s". 

b) The Content-Disposition field shall be present. The value of the header shall be "attachment". An additional 
"filename" parameter shall be provided that has the value "smime.p7s". 

Every REM-MD Message generated by a REM-MD shall include the field Content-Disposition and fill in the 
name/filename parameters. To maximize the level of interoperability the REM-MDs shall be able to correctly 
interpret incoming messages without the presence of Content-Disposition and/or name/filename parameters. 

5.3.3 REM-MD Introduction Headers Constraints 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


X-REM-Section-Type 


Clause 4.4 


M 


a 





Implementation guidance: 

a) A X-REM-Section-Type header shall be provided that has the value "rem_message/introduction". 



5.3.3.1 



Multipart/alternative: Free text subsection header constraints 



N 2 


Service/Protocol 
element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Content-Type 


Clause 4.4.1 


R 


a 





Implementation guidance: 

a) The value for this field shall be: "text/plain;". It also is recommended that this field assumes also the value 
charset="UTF-8". 



5.3.3.2 



Multipart/alternative: Html subsection header constraints 



N 2 


Service/Protocol 
element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Content-Type 


Clause 4.4.2 


R 


a 





Implementation guidance: 

a) The value for this field shall be: "text/html;". It also is recommended that this field assumes also the value 
charset="UTF-8". 

5.3.4 Original Message MIME Section headers constraints 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


X-REM-Section-Type 


Clause 4.5 


M 


a 
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Implementation guidance: 

a) A X-REM-Section-Type header shall be provided that has the value "rem_message/original". 

5.3.5 REM-MD Evidence MIME Section headers constraints 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


X-REM-Section-Type 


Clause 4.6 


M 


a 





Implementation guidance: 

a) A X-REM-Section-Type header shall be provided that has the value "rem_message/evidence". 



N 2 


Service/Protocol 
element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


2 


Content-Type 


Clause 4.6.2 


M 


a 





Implementation guidance: 

a) The value for this field shall be: "application/xml;" and name/charset fields shall assume the values specified 
intheTS 102 640-2 [2]. 

The present profile requires that at least the evidence in XML format (defined in clause 4.6.2 of TS 102 640-2 [2]) 
is present in all the REM-MD messages. 

Optionally the PDF format, a defined in clause 4.6.3 of TS 102 640-2 [2], may be present. 

NOTE: If the optional evidence in PDF format carries an embedded XML structure, it shall replicate the data in 
the mandatory XML evidence. 

5.3.6 REM-MD Extensions MIME Section headers constraints 

The present extension is optional and, when present, is contained in a XML attachment of the REM-MD Message. If it 
is present the following restrictions apply. 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


X-REM-Section-Type 


Clause 4.7 


M 


a 





Implementation guidance: 

a) A X-REM-Section-Type header shall be provided that has the value "rem_message/extensions". 



5.4 



REM-MD evidence 



5.4.1 REM-MD Evidence types 



5.4.1 .1 Mandatory evidence - all styles of operation 

The following evidence types specified in the indicated TS 102 640-2 [2] clauses are always required. 



ETSI 



11 



ETSI TS 102 640-5 V2.1.1 (2010-01) 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


SubmissionAcceptanceRejection 


Clause 5.1.1 


M 


a 


see note 1 


2 


DeliveryNonDeliveryToRecipient 


Clause 5.1.4 


M 


b 


see note 2 


NOTE 1 : Rationale: The sender shall be aware of the successful/unsuccessful outcome of his/her message 

submission. 
NOTE 2: Rationale: The sender shall have evidence on whether the recipient was/was not delivered: 

- The original message he/she sent (where the sender's REM-MD style of operation is "S&F"). 

- The notification the sender's REM-MD generated in relation to the original message (where the sender's 
REM-MD style of operation is "S&N"). 



Implementation guidance: 

a) The sender's REM-MD shall include the SubmissionAcceptanceRejection (obviously related to a successful 
submission) in the REM Dispatch(es) to be forwarded to the final recipient(s). 

b) The recipient's REM-MD shall send back to the sender one REM-MD Message including the 
DeliveryNonDeliveryToRecipient evidence. 



5.4.1.2 



Mandatory evidence - S&N style of operation 



The following evidence types specified in the indicated TS 102 640-2 [2] clause is always required for messages 
conveyed to the recipient by reference. 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


DownloadNonDownloadBy Recipient 


Clause 5.1.5 


M 


a 


see note 


NOTE: Rationale: The sender needs to have evidence on whether the recipient downloaded/non downloaded within 
a predefined time period the Original Message referenced in the notification. 



Implementation guidance: 

a) The recipient's REM-MD shall send back to the sender one REM-MD Message including the 
DownloadNonDownloadByRecipient. 



5.4.1.3 



Conditional evidence - all styles of operation 



To the following evidence types, specified in the indicated TS 102 640-2 [2] clauses, the below specified conditions 
apply. 



N 2 


Service/Protocol element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


Relay ToREMMDAcceptanceRejection 


Clause 5.1.2 


Conditional "M" 


a, b, c 


see note 


2 


Relay ToREMMDFailure 


Clause 5.1.3 


Conditional "M" 


d, e 


see note 


NOTE: Rationale for both evidence types: the sender needs to know if the sent message did not successfully reach, 
or was rejected by, the recipient's REM-MD, to enact possible backup measures. 



Implementation guidance: 
a) Mandatory if: 

no opposite provision is explicitly specified in the applicable REM-PD rules; 

no previous opposite agreement exists between the involved REM-MDs. 
Such agreement or policy provision should specify one of the following: 

I) The sender's REM-MD will assume that one REM-MD Message has been rejected by the recipient's REM-MD 
if no contrary indication is received within a predefined time period. 

II) The sender's REM-MD will assume that one REM-MD Message has been accepted by the recipient's 
REM-MD if no contrary indication is received within a predefined time period. 
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Alternative conditions may be specified in the above agreement, provided that the issue is exhaustively dealt with. 

b) If this Evidence type is mandatory, the recipient's REM-MD shall send back to the sender's REM-MD one 
REM-MD Message including the Relay ToREMMDAcceptanceRejection. 

c) In the cases addressed in the previous item a)I) and item a)II), the sender's REM-MD shall build a REM-MD 
Message, including one Relay ToREMMDAcceptanceRejection Evidence and shall send it to the sender. 

d) Mandatory if no opposite requirement within REM-PD exists. 

Such policy requirement should specify that, if no contrary indication is received within a predefined time 
period, it is to be assumed that it was impossible to deliver one REM-MD Envelope within a given time period 
to the recipient's REM-MD, due to any kind of problems. 
Alternative conditions may be specified in the above policy, provided that the issue is exhaustively dealt with. 

e) The sender's REM-MD shall build a REM-MD Message, including one Relay ToREMMDFailure Evidence 
and shall send it back to the sender. 

5.4.2 REM-MD Evidence components 

In the following clauses, details on the Evidence Components are listed for each "Mandatory Evidence type" indicated 
in above clauses from 5.4.1.1 through 5.4.1.3. The line of conduct adopted in the following subclauses of this clause 
differs from the one adopted in the other clauses of the present document. More in detail, the following clauses list all 
Evidence Components that are required to ensure interoperability, including those that in TS 102 640-2 [2] are already 
indicated as mandatory or whose absence implies a value by default. 

NOTE: This different line of conduct has been adopted to give a more complete and comfortable view to the 
reader. 



5.4.2.1 



SubmissionAcceptanceRejection - clause 5.1.1 



N 2 


Evidence element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


REM-MD Evidence Identifier 


GOO 


M 




see note 1 


2 


REM-MD Evidence Type = 
"SubmissionAcceptanceRejection" 


G01 


M 




see note 1 


3 


REM Event 


G02 


M 




see note 1 


4 


Reason code 


G03 


M(1..N) 


a 


see note 1 


5 


REM-MD Evidence Version 


G04 


M 




see note 1 


6 


Event Time 


G05 


M 




see note 1 


7 


REM-MD Evidence issuer Policy 
Identifier 


R01 


M(1..N) 




see note 1 


8 


REM-MD Evidence issuer Details 


R02 


M 




see note 1 


9 


Sender's details 


I00 


M 




see note 1 


10 


Recipient's details 


101 


M(1..N) 




see note 1 


11 


Sender Authentication details 


I04 


O 


b 


see note 2 


12 


REM-MD Message/REM Dispatch 
details 


MOO 


M 




see note 1 


13 


Reply-to 


M01 


M 


c 




14 


Message Submission Time 


M03 


M 


d 




NOTE 1 : Readers are reminded that this requirement is present as mandatory in TS 1 02 640-2 [2]. 
NOTE 2: Readers are reminded that this requirement is present with a default value in TS 102 640-2 [2]. 



Implementation guidance: 

a) At least one Reason Code shall be present, unless the applicable REM-PDs explicitly require that when 
submission is regularly accepted no Reason Code is necessary. 

Multiple Reason Code may be present depending on the found exceptions. 

b) If this field is not present it means that the class of authentication is Basic. In the other cases it specifies the 
class of Authentication. 
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c) This field shall be present containing the email address of the original sender, unless the applicable REM-PDs 
explicitly require that no Reply-to is necessary. 

d) This field shall be present. 



5.4.2.2 



DeliveryNonDeliveryToRecipient - clause 5.1.4 



N 2 


Evidence element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


REM-MD Evidence Identifier 


GOO 


M 




see note 


2 


REM-MD Evidence Type = 
"DeliveryNonDeliveryToRecipient" 


G01 


M 




see note 


3 


REM Event 


G02 


M 




see note 


4 


Reason code 


G03 


M(1..N) 


a 




5 


REM-MD Evidence Version 


G04 


M 




see note 


6 


Event Time 


G05 


M 




see note 


7 


REM-MD Evidence issuer Policy 
Identifier 


R01 


M(1..N) 




see note 


8 


REM-MD Evidence issuer Details 


R02 


M 




see note 


9 


Sender's details 


I00 


M 




see note 


10 


Recipient's details 


101 


M(1..N) 




see note 


11 


Recipient referred to by the Evidence 


I03 


M 


b 




12 


REM-MD Message/REM Dispatch 
details 


MOO 


M 




see note 


13 


Notification Message Tag 


M02 


O 


c 




NOTE: Readers are reminded that this requirement is present as mandatory in TS 1 02 640-2 [2]. 



Implementation guidance: 

a) At least one Reason Code shall be present, unless the applicable REM-PDs explicitly require that when 
delivery regularly occurred no Reason Code is necessary. 

Multiple Reason Code may be present depending on the found exceptions: 

b) This field shall be present. 

c) This field shall be present with value TRUE if the REM-MD Message to which this evidence refers is a 
notification. Otherwise, if this evidence refers to a REM-MD Message that includes the Original Message, it 
may be absent or assume the value FALSE. 



5.4.2.3 



DownloadNonDownloadByRecipient - clause 5.1 .5 



N 2 


Evidence element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


REM-MD Evidence Identifier 


GOO 


M 




see note 


2 


REM-MD Evidence Type = 
"DownloadNonDownloadByRecipient" 


G01 


M 




see note 


3 


REM Event 


G02 


M 




see note 


4 


Reason code 


G03 


M(1..N) 


a 




5 


REM-MD Evidence Version 


G04 


M 




see note 


6 


Event Time 


G05 


M 




see note 


7 


REM-MD Evidence issuer Policy Identifier 


R01 


M(1..N) 




see note 


8 


REM-MD Evidence issuer Details 


R02 


M 




see note 


9 


Sender's details 


I00 


M 




see note 


10 


Recipient's details 


101 


M(1..N) 




see note 


11 


Recipient referred to by the Evidence 


I03 


M 


b 




12 


Recipient Authentication details 


I05 


O 


c 




13 


REM-MD Message/REM Dispatch details 


MOO 


M 




see note 


NOTE: Readers are reminded that this requirement is present as mandatory in TS 1 02 640-2 [2]. 
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Implementation guidance: 

a) At least one Reason Code shall be present, unless the applicable REM-PDs explicitly require that when 
download regularly occurred no Reason Code is necessary. 

Multiple Reason Code may be present depending on the found exceptions. 

b) This field shall be present. 

c) If this field is not present it means that the class of authentication is Basic. In the other cases it specifies the 
class of Authentication. 



5.4.2.4 



RelayToREMMDAcceptanceRejection - clause 5.1 .2 



N 2 


Evidence element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


REM-MD Evidence Identifier 


GOO 


M 




see note 


2 


REM-MD Evidence Type = 

Relay ToREMMDAcceptanceRejection 


G01 


M 




see note 


3 


REM Event 


G02 


M 




see note 


4 


Reason code 


G03 


M(1..N) 


a 




5 


REM-MD Evidence Version 


G04 


M 




see note 


6 


Event Time 


G05 


M 




see note 


7 


REM-MD Evidence issuer Policy 
Identifier 


R01 


M(1..N) 




see note 


8 


REM-MD Evidence issuer Details 


R02 


M 




see note 


10 


Sender's details 


I00 


M 




see note 


11 


Recipient's details 


101 


M(1..N) 




see note 


12 


Recipient referred to by the Evidence 


I03 


M 




see note 


13 


REM-MD Message/REM Dispatch 
details 


MOO 


M 




see note 


14 


Notification Message Tag 


M02 


M 




see note 


NOTE: Readers are reminded that this requirement is present as mandatory in TS 1 02 640-2 [2]. 



Implementation guidance: 

a) At least one Reason Code shall be present, unless the applicable REM-PDs explicitly require that when the 
relay to the recipient's REM-MD regularly occurred no Reason Code is necessary. 

Multiple Reason Code may be present depending on the found exceptions. 



5.4.2.5 



RelayToREMMDFailure - clause 5.1 .3 



N 2 


Evidence element 


TS 102 640-2 [2] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


REM-MD Evidence Identifier 


GOO 


M 




see note 


2 


REM-MD Evidence Type = 
"RelayToREMMDFailure" 


G01 


M 




see note 


3 


REM Event 


G02 


M 




see note 


4 


Reason code 


G03 


M(1..N) 


a 




5 


REM-MD Evidence Version 


G04 


M 




see note 


6 


Event Time 


G05 


M 




see note 


7 


REM-MD Evidence issuer Policy 
Identifier 


R01 


M(1..N) 




see note 


8 


REM-MD Evidence issuer Details 


R02 


M 




see note 


9 


Sender's details 


I00 


M 




see note 


11 


Recipient's details 


101 


M(1..N) 




see note 


12 


Recipient referred to by the Evidence 


I03 


M 




see note 


13 


REM-MD Message/REM Dispatch 
details 


MOO 


M 




see note 


14 


Notification Message Tag 


M02 


M 




see note 


NOTE: Readers are reminded that this requirement is present as mandatory in TS 1 02 640-2 [2]. 
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Implementation guidance: 



a) At least one Reason Code shall be present, unless the applicable REM-PDs explicitly require that when relay 
to the recipient's REM-MD failed no Reason Code is necessary. 

Multiple Reason Code may be present depending on the found exceptions. 
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Annex A (informative); 
Bibliography 



ETSI TS 102 640-4: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); 
Part 4: REM-MD Conformance Profiles". 
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